-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wayland qt kde clipboard fix #863
Wayland qt kde clipboard fix #863
Conversation
c261a6f
to
3c2143f
Compare
The change looks good to me and I confirm it fixes the issue. |
3c2143f
to
c50b990
Compare
c50b990
to
3fd6842
Compare
@akurtakov |
enables paste from KDE/QT apps to Eclipse in a wayland session.
…wayland clipboard Enables copy from eclipse to KDE/QT apps in a wayland session(RFC-1341)
Most likely due eclipse-tycho/tycho#2996 |
3fd6842
to
666b7fd
Compare
OK |
@akurtakov |
Build failure seems to happen everytime between reference to new native is committed, and an I-Build is available. Let's just merge anyway (which is relatively risky, but that's worth taking the risk as long as we've not fixed the build to prevent the error from happening on unrelated changes). |
@the-snowwhite Thank you! |
Please don't merge things if they cannot be built. At least the root cause should have been identified and addressed somehow. |
Look at history and CI checks, you'll see it's unfortunately be the only productive workflow so far as no-one seems to be eager to fix it. I agree it's not good, but our failure to stabilize CI shouldn't be a reason for preventing locally tested patches from being merged if there is enough confidence in the patch. |
Not sure which history you mean. I'm not aware about broken builds in SWT.
If no one reports a problem, it unlikely goes away. |
All I can find on this build issue is the log entity:
here: @mickaelistria |
The first build of this PR was a success: |
@iloveeclipse
to the build.properties file ? @akurtakov |
I will have a look in an hour or two, here is the reason why one should never ignlre build fails: |
@the-snowwhite There is nothing related to this patch IMHO #867 (comment) . Of course, we will be really thankful if you look into the build failure which lies somewhere in the Ant build files of swt somewhere (95% sure I am) and would have happened without your patch.. |
@akurtakov |
// This is a simplified example; actual encoding depends on RFC-1341 standards | ||
// String rfc1341Text = "Content-Type: " + TEXTPLAINUTF8 + "\r\n\r\n" + text; | ||
String rfc1341Text = text; | ||
return rfc1341Text.getBytes(StandardCharsets.UTF_8); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please see #875 (comment)
I have my doubts what this method does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe the method should be named convertToUTF8
, as RFC 1341 is the standard that talks about the formatting if "MIME types" (i.e. the maintype/subtype;options
format), and isn't actually about UTF strings. Also, the code of the method is pretty simple - effectively a short one liner - so maybe it can just be used directly in the one place it is being used.
@@ -169,6 +169,9 @@ boolean setData(Clipboard owner, Object[] data, Transfer[] dataTypes, int clipbo | |||
System.arraycopy(entries, 0, tmp, 0, entries.length); | |||
tmp[entries.length] = entry; | |||
entries = tmp; | |||
TransferData tdata = new TransferData(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change is non-functional. Why it was added?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These 3 lines where needed to get Eclipse to present text/plain;uft-8 data to the clipboard.
Otherwise the javaToNative function in Texttreanfer.java was'nt called.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This I confirmed by the eclipse debugger
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is wrong - have you asked why does the rest of clipboard data works but only new type would need that? I would assume you've missed something else.
The javaToNative is called from org.eclipse.swt.dnd.ClipboardProxy.getFunc(long, long, long, long)
1) The utf-8 content should be same as in UTF8_STRING, it just should use different label/type id. 2) The change in ClipboardProxy.setData() was non functional and makes no sense, it only leaks memory/wastes time See eclipse-platform#863 See eclipse-platform#851
The change here is not OK. |
I now know the buzzwords are:
#851 (comment)
However the main motivation here is:
"Being able to use Eclipse comfortably with a LTS based linux distro in a wayland session in 2023"
The first commit already has an open pr #861 the second has been tested to work via this method #858
and then cherry picked from R_29_maintenance branch onto master without any issues.